home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HamCall (October 1991)
/
HamCall (Whitehall Publishing)(1991).bin
/
amateur
/
w0rli
/
mb1202.exe
/
lha
/
SID.DOC
< prev
next >
Wrap
Text File
|
1991-03-09
|
4KB
|
104 lines
System IDentifiers (SIDs)
The initial exchange between "smart" MailBox systems uses what is called
an "SID", short for System IDentifier. All future work on MailBox systems
should adopt this standard. It will help to remove a GREAT deal of
confusion as to which systems have what features, and how one should
interface to them. In the longer future, perhaps all this junk can be
done away with, and the computers can talk to each other in a more
natural way.
The system identifier is structured:
"[f1-f2-f3]"
The dashes delimit the end of the first field and the start of the last.
There might be only one dash, if f2 is void. f2 may contain dashes.
f1, f2, and f3 may not contain "[" or "]".
f1 is the author identification. It may not contain a dash.
Normally it will contain a few characters from the authors callsign.
f2 is author specific data.
It may contain anything the author wishes, for example software version.
It may contain dashes.
f3 is the supported feature set. It may not contain a dash.
It contains a string of non-numeric characters, one for each negotiable
feature supported. Each character may also have trailing digits, giving
the revision of that feature. If there is no trailing digit, the
feature revision is revision zero.
Defined features are:
C - Supports "forwarding" of date and time (obsolete).
H - Supports hierarchical location identifiers.
M - Supports message identifiers.
R - Supports extended forwarding responses.
Y - Supports YAPP binary protocol (unused).
$ - Supports BID. MUST BE LAST CHARACTER IN f3 for downward compatibility.
The existance of the system ID implies that the system supports
reverse forwarding and OK/NO message rejection.
Some examples of existing standard system identifiers:
[RLI-12.0-H$] - w0rli version 12.0, supports BID and H location.
[CBBS-5.1-$] - ag3f release of the rli/gyq cbbs.
[MSYS-1.08-H$] - wa8bxn version 1.08, supports BID and H location.
[MBL-5.14-H$] - wa7mbl V5.12, supports BID and H location.
[4RE-2.3-MH$] - aa4re V2.3, supports MID, BID, and H location.
The connect rules:
Send the SID as first line at connect.
Answer the SID (when seen as a command) with a short command prompt.
The forwarding rules:
If you do not see an SID at connect, use the old style fowarding.
This handles the case of Xerox 820 systems, for example.
If you do see an SID at connect, answer with your SID.
Use whatever features are appropriate.
The message entry command:
Sx TO [@ BBS[.LOC]] [< FROM] [$[BID]]
x may be B, T, or P.
If x is absent, P is assumed if TO is a callsign, otherwise B is assumed.
The $ is not part of the BID, but identifies the field.
There is no space between the $ and the BID.
The spaces surrounding the @ may be omitted.
OK/NO message rejection.
Instead of sending the "S" command and Title, send only the "S" command.
The remote system will reply with either OK or NO, possibly followed by
some text. If the response is NO, it will be followed by a prompt. If the
response is OK, then go ahead and forward the message. Usually, NO will
only be seen if you attempt to forward a message with BID already known
to the receiving system. It may also be seen in the case of full disk, or
any other reason the system does not want the message. Possiblities under
discusion range from "I do not handle NTS traffic." to "I do not know that
user, nor any route to reach him."